Built-in Directives for Designating the Current Section

.text

This is equivalent to .section __TEXT,__text,regular,pure_instructions

The compiler only places machine instructions in the (__TEXT,__text) section (no read-only data, jump tables or anything else). With this the entire (__TEXT,__text) section is pure instructions and tools that operate on object files can take advantage of this and can locate the instructions of the program and not get confused with data that could have been mixed in. To make this work all run-time support code linked into the program must also obey this rule (all Mac OS X library code follows this rule).

.const

This is equivalent to .section __TEXT,__const

The compiler places all data declared const in this section and all jump tables it generates for switch statements.

.static_const

This is equivalent to .section __TEXT,__static_const

This is not currently used by the compiler. It was added to the assembler so that the compiler may separate global and static const data into separate sections if it wished to.

.cstring

This is equivalent to .section __TEXT,__cstring, cstring_literals

This section is marked with the section type S_LITERAL_CSTRING, which the link editor recognizes. The link editor merges the like literal C strings in all the input object files to one unique C string in the output file. Therefore this section must only contain C strings (a C string in a sequence of bytes that ends in a null byte, '\0', and does not contain any other null bytes except its terminator). The compiler places literal C strings found in the code that are not initializers and do not contain any imbedded nulls in this section.

.literal4

This is equivalent to .section __TEXT,__literal4,4byte_literals

This section is marked with the section type S_4BYTE_LITERALS, which the link editor recognizes. The link editor then can merge the like 4 byte literals in all the input object files to one unique 4 byte literal in the output file. Therefore this section must only contain 4 byte literals. This is typically intended for single precision floating-point constants and the compiler uses this section for that purpose. On some machines it is more efficient to place these constants in line as immediates as part of the instruction.

.literal8

This is equivalent to .section __TEXT,__literal8,8byte_literals

This section is marked with the section type S_8BYTE_LITERALS, which the link editor recognizes. The link editor then can merge the like 8 byte literals in all the input object files to one unique 8 byte literal in the output file. Therefore this section must only contain 8 byte literals. This is typically intended for double precision floating-point constants and the compiler uses this section for that purpose. On some machines it is more efficient to place these constants in line as immediates as part of the instruction.

.constructor

This is equivalent to .section __TEXT,__constructor
(__TEXT,__destructor)

This is equivalent to .section __TEXT,__destructor

These sections are used by the C++ run-time system, and are reserved exclusively for the C++ compiler.

.fvmlib_init0

This is equivalent to .section __TEXT,__fvmlib_init0

.fvmlib_init1

This is equivalent to .section __TEXT,__fvmlib_init1

These two sections are used by the fixed virtual memory shared library initialization. The compiler doesn't place anything in these sections, as they are reserved exclusively for the shared library mechanism.

.symbol_stub

This is equivalent to .section __TEXT,__symbol_stub, symbol_stubs, pure_instructions,NBYTES

This section is of type symbol_stubs and has the attribute pure_instructions. The compiler places symbol stubs in this section for undefined functions that are called in the module. This is the standard symbol stub section for non position-independent code. The value NBYTES is dependent on the target architecture. The standard symbol stub for the PowerPC is 20 bytes and has an alignment of 4 bytes (. align 2 ) . For example, a stub for the symbol _foo would be (using a lazy symbol pointer L_foo$lazy_ptr ):

        symbol_stub Lfoo$stub:         .indirect_symbol _foo         lis     r11,ha16(L_foo$lazy_ptr)         lwz     r12,lo16(L_foo$lazy_ptr)(r11)         mtctr   r12         addi    r11,r11,lo16(L_foo$lazy_ptr)         bctr          .lazy_symbol_pointer L_foo$lazy_ptr:         .indirect_symbol _foo         .long   dyld_stub_binding_helper

The standard symbol stub for the i386 is 16 bytes and has an alignment of 1 byte (. align 0 ). For example a stub for the symbol _foo would be (using a lazy symbol pointer L_foo$lazy_ptr ):

        .symbol_stub Lfoo$stub:         .indirect_symbol _foo         ljmp    L_foo$lazy_ptr Lfoo$stub_binder:         pushl   $L_foo$lazy_ptr         jmp     dyld_stub_binding_helper          .lazy_symbol_pointer L_foo$lazy_ptr:         .indirect_symbol _foo         .long   Lfoo$stub_binder

.picsymbol_stub

This is equivalent to .section __TEXT, __picsymbol_stub, symbol_stubs, pure_instructions, NBYTES

This section is of type symbol_stubs and has the attribute pure_instructions. The compiler places symbol stubs in this section for undefined functions that are called in the module. This is the standard symbol stub section for position-independent code. The value of NBYTES is dependent on the target architecture.

The standard position-independent symbol stub for the PowerPC is 36 bytes and has an alignment of 4 bytes (. align 2 ). For example a stub for the symbol _foo would be (using a lazy symbol pointer L_foo$lazy_ptr ):

        .picsymbol_stub Lfoo$stub:         .indirect_symbol _foo         mflr     0         bl       LO$foo LO$foo:         mflr     r11         mtlr     r0         addis    r11,r11,ha16(L_foo$lazy_ptr - LO$foo)         lwz      r12,lo16(L_foo$lazy_ptr - LO$foo)(r11)         mtctr    r12         addi     r11,r11,lo16(L_foo$lazy_ptr - LO$foo)         bctr          .lazy_symbol_pointer L_foo$lazy_ptr:         .indirect_symbol _foo         .long   dyld_stub_binding_helper

The standard position-independent symbol stub for the i386 is 26 bytes and has an alignment of 1 byte (. align 0 ). For example a stub for the symbol _foo would be (using a lazy symbol pointer L_foo$lazy_ptr ):

        .picsymbol_stub Lfoo$stub:         indirect_symbol _foo         call   L1foo$stub L1foo$stub:         popl    %eax         movl    L_foo$lazy_ptr-L1foo$stub(%eax),%ebx         jmp     %ebx Lfoo$stub_binder:         lea     L_foo$lazy_ptr-L1foo$stub(%eax),%eax         pushl   %eax         jmp dyld_stub_binding_helper          .lazy_symbol_pointer L_foo$lazy_ptr:         .indirect_symbol _foo         .long   Lfoo$stub_binder

.data

This is equivalent to . section __DATA, __data

The compiler places all non-const initialized data (even initialized to zero) in this section.

.static_data

This is equivalent to . section __DATA, __static_data

This is not currently used by the compiler. It was added to the assembler so that the compiler could separate global and static data symbol into separate sections if it wished to.

.non_lazy_symbol_ptr

This is equivalent to .section __DATA, __nl_symbol_ptr,non_lazy_symbol_pointers

This section is of type non_lazy_symbol_pointers and has no attributes. The compiler places a non-lazy symbol pointer in this section for each undefined symbol referenced by the module (except for function calls). This section has an alignment of 4 bytes (. align 2 ).

.lazy_symbol_ptr

This is equivalent to . section __DATA, __la_symbol_ptr,lazy_symbol_pointers

This section is of type lazy_symbol_pointers and has no attributes. The compiler places a lazy symbol pointer in this section for each symbol stub it creates for undefined functions that are called in the module. (See __TEXT, __symbol_stub for examples.) This section has an alignment of 4 bytes (. align 2 ).

.dyld

This is equivalent to .section __DATA, __dyld,regular

This section is of type regular and has no attributes. This section is used by the dynamic link editor. The compiler doesn't place anything in this section, as it is reserved exclusively for the dynamic link editor.

.mod_init_func

This is equivalent to .section __DATA, __mod_init_func, mod_init_funcs

This section is of type mod_init_funcs and has no attributes. The C++ compiler places a pointer to a function in this section for each function it creates to call the constructors (if the module has them).

.const_data

This is equivalent to .section __DATA, __const, regular .

This section is of type regular and has no attributes. This section is used when dynamic code is being compiled for const data that must be initialized.